Dynamic Routing Implementation

Sprint to the finish

Paul M. Washburn

June 2017

Executive Summary

Updates

  • Call w/ [OTHER COMPANY] helpful - not perfect fit
  • All houses reporting quality data; kicking off testing
  • Our disaster recovery plan failed its first live test
  • Roadnet failed once again Tuesday - inadequate support
  • The team is at or near capacity w/ non-related work
  • We are entering the sprint to the finish, ETA 8/1
  • STL-caused delay: semi-dynamic routes (routes v. stops)
  • Next week is the on-site meeting w/ Omnitracs

[OTHER COMPANY] Profile

  • Use on-premise version; DR is collaborative w/ RN
  • On-premise is easier to create a DR plan
  • Services ~300 customers & ~31 routes per day from DC
  • Each route typically has about 5-10 stops (may change)
  • Use dynamic quarterly to re-optimize their routes
  • Use telematics & log units to track & communicate
  • Enforces driver start times, 6AM firm
  • One dedicated person to “own” the data in RNA
  • Instituted new driver training program to set expectations
  • Emphasized effective communication w/ clients/drivers
  • Emphasized that “someone will always be upset”

Pressing Issues to Address

  • Need objective way of measuring LOS; need target
  • Tradeoff between LOS & cost; cannot achieve both
  • Disaster recovery plan; may need Omnitracs to build
  • Driver Start Times; need to be instituted ASAP
  • Backup plan for if drivers reject tool; internal subs?
  • Set expectations w/ Drivers/Customers; communicate!
  • Roadnet routing failures; 3rd time their support failed us
  • Merchandisers; telematics/driver start-times are key
  • Ongoing collection of time windows; who? when? how?
  • Sales to Customers: provide realistic expectations
  • Current failure rate insufficient to move to new ERP

Level-of-Service Metric Design

As of now we do not have a go-to metric of LOS, so we must design one based on available heuristics.

To adequately measure level of service we must account for:

  • On-time deliveries at the customer level
  • Measurement errors from Roadnet and/or personnel
  • Whether the account is merchandised or not

We could account for:

  • Percent of customers receiving next day delivery
  • Percent of customers within X mile radius

Bottom line: we need an objective metric that will guide all activity

LOS vs. Cost to Deliver

Service levels and cost of delivery have a strong positive relationship. Because of this it will be impossible to achieve minimum costs and maximum service levels.

It is up to us to determine what an adequate level of service is, and how much we are willing to pay for it.

  • Any LOS metric we choose is at odds with cost
  • We must reverse engineer from desired LOS
  • We should run scenarios to determine cost of LOS
  • Scenario planning helps in stress testing as well

Disaster Recovery

Currently we do not track certain vital data in the AS400. These include (1) start/end delivery windows, (2) static & semi-dynamic route templates, and (3) service window importance.

  • RNA App makes it difficult to backup data
  • Route templates must be backed up 1 by 1; 100’s
  • We have manual backups for everything post issues
  • RNA’s export format is not sufficient to upload back in
  • Our customer updating process has exhibited weaknesses

This process should be very easy, but it has been made incredibly difficult by Omnitrac’s poor engineering capability. The fact that we are talking about (paying them) them to create an extremely simple report (customer ID, start time, end time) is simply unacceptable. This should be easy, yet it is a huge obstacle for our IT team

Driver Start Times

There is no scenario in which we succeed at dynamic routing and improve service levels (not to mention conflict between merchandising/operations) where we do not institute start times for all drivers statewide.

  • Issues w/ unions; issues w/ Hogan
  • Communication with all parties insufficient
  • Need to make drivers feel OK about RNA
  • Under dynamic, start times will change daily

It may be prudent to identify internal or external driver backups. This is an insurance policy, in the event we have more drivers quit than we anticipate.

On-going Time Window Collection

We need guidance ASAP as to (1) who will collect time windows, (2) how often, (3) how the party will be held accountable, and (4) how it will be input to Roadnet.

Naive proposition:

  • Customer Service/Internal Sales ask the question 1x/qtr
  • Drivers make it part of driver check-in to update
  • One person made the “owner” of all Roadnet data
  • If sales hears of changes, contact person above

Merchandising/Driver Coordination

Currently, operations’ inability to communicate driver arrival times accurately is costing the merchandising team time and money. These conflicts are on-going and preventable.

  • Without telematics or start times we will be out of sync
  • High conflict levels b/n merchandising & operations
  • Operations somewhat inflexible currently w.r.t merch.
  • With telematics, merchandiser can simply login to RNA
  • Costs here add up quickly: Sam’s before & after 7AM

Pre-emptive Communication

It would be prudent to issue preliminary communications to drivers, customers & sales to set expectations for when dynamic routing is live.

[OTHER COMPANY] highlighted that they could have saved considerable aches & pains if they had communicated more effectively upfront with their drivers and with their customers.

It would also be helpful to ask Sales not to set unrealistic expectations about delivery times to customers.

Project Information

Decisions

Timeline

## $key
##  [1]  1  2  3  4  5  6  7  8  9 10 11 12
## 
## $description
##  [1] "Enumerate Questions Final Consult"              
##  [2] "Final Roadnet Consultation Onsite"              
##  [3] "Document SOP & Parameters for Dynamic"          
##  [4] "Best Practices Inquiry w/ Current Users"        
##  [5] "Final Approval from Sales/Merchandising"        
##  [6] "Ensure All Backups Accounted For"               
##  [7] "Outline Plan to Sales; Gain Approval"           
##  [8] "Communicate Dynamic Plan to Drivers"            
##  [9] "Institute Starting Times for Drivers"           
## [10] "Plan for Ongoing Collection of Windows"         
## [11] "Dynamic Route Day's Orders; Document/Experiment"
## [12] "Go Live Dynamic Routing All Routes"             
## 
## $start
##  [1] "2017-03-25 CDT" "2017-06-08 CDT" "2017-02-17 CST" "2017-05-31 CDT"
##  [5] "2017-02-20 CST" "2017-03-17 CDT" "2017-05-11 CDT" "2017-04-21 CDT"
##  [9] "2017-05-11 CDT" "2017-05-31 CDT" "2017-02-02 CST" "2017-07-15 CDT"
## 
## $end
##  [1] "2017-06-05 CDT" "2017-06-09 CDT" "2017-06-11 CDT" "2017-06-21 CDT"
##  [5] "2017-07-01 CDT" "2017-07-01 CDT" "2017-07-07 CDT" "2017-07-15 CDT"
##  [9] "2017-07-15 CDT" "2017-07-15 CDT" "2017-07-31 CDT" "2017-08-01 CDT"
## 
## $done
##  [1] 95  0 60 50 25 75 50  5  5  5 88  0
## 
## $neededBy
##  [1] NA NA NA NA NA NA NA NA NA NA NA NA
## 
## attr(,"class")
## [1] "gantt"

Task List

Risk Matrix

Risks

Objectives

Metrics

Steering Committee Guidance

Team Needs from Steering Committee

  • Develop LOS metric; begin targeting certain levels
  • Begin driver start times; communicate w/ drivers
  • Get serious about our disaster recovery plan
  • Hold Omnitracs accountable for poor service/product
  • Consider investment in telematics
  • Decide who/when/how will maintain RNA data

Questions? Comments?

Parting Words of Wisdom from Clayton M. Christensen
“An innovation will get traction only if it helps pe ople get something that they’re already doing in their lives done better.”